Cryptext x64 Argon2id Extra Edition – Preview 3
Native scrypt-Integration

Projektbeschreibung

Cryptext x64 verbindet ein authentifiziertes AES-256-GCM-Dateiformat mit einer
wählbaren Passwort-Schlüsselableitung. Preview 3 ergänzt scrypt als vierte
Auswahl im Infodialog. PBKDF2 sowie die beiden Argon2id-Profile bleiben erhalten.
Die scrypt-Routinen sind direkt in FASM-x64-Assembler implementiert und werden
in den ausführbaren Codeabschnitt der EXE eingebunden. Es werden weder eine
zusätzliche scrypt-DLL noch ein Overlay oder eine C-Laufzeitbibliothek benötigt.

Algorithmus und Parameter

scrypt nach RFC 7914: N = 262144, r = 8, p = 1, Ausgabelänge = 32 Byte.
Das Passwort wird als UTF-16LE ohne abschließendes Nullzeichen und ohne Unicode-
Normalisierung verarbeitet. Jede Datei erhält ein zufälliges 16-Byte-Salt.

Der Ablauf besteht aus PBKDF2-HMAC-SHA-256 mit einer Iteration und 1024 Byte
Ausgabe, ROMix mit Salsa20/8 und abschließend erneut PBKDF2-HMAC-SHA-256 mit
einer Iteration und 32 Byte Ausgabe. Diese beiden PBKDF2-Schritte gehören zu
scrypt; sie sind kein Rückfall auf die separat auswählbare PBKDF2-Methode.
Für HMAC/PBKDF2 wird die bereits genutzte Windows-CNG-API eingesetzt. Die
speicherharte Berechnung einschließlich Salsa20/8 erfolgt im nativen Assembler.
Windows-Systembibliotheken wie bcrypt.dll bleiben deshalb erforderlich.

Speicherverwaltung

Die ROMix-Matrix umfasst exakt 128 * r * N = 268435456 Byte = 256 MiB.
VirtualAlloc reserviert und aktiviert sie mit MEM_RESERVE | MEM_COMMIT und
PAGE_READWRITE. Dieser Arbeitsspeicher ist nicht ausführbar. Ein C-Allocator
wird nicht verwendet. Vor VirtualFree wird die vollständige Matrix explizit
mit Null überschrieben. B, X und Y beanspruchen zusammen weitere 3072 Byte auf
dem Stack und werden ebenfalls gelöscht. Der Schlüssel wird bei Fehlern genullt.

256 MiB ist die Größe der Matrix, nicht der gesamte RAM-Bedarf von Cryptext.
Zusätzlich entstehen Stack-, CNG-, Programm- und Dateipufferbedarf. Der EXE-Header
reserviert ausdrücklich 1 MiB virtuellen Stack, zunächst mit 4 KiB Commit. Diese
Reservierung ist kein weiterer dauerhaft belegter 1-MiB-Arbeitspuffer.
Bei Allokations- oder Ableitungsfehlern wird abgebrochen. Das Programm wechselt
nicht automatisch zu einem speicherärmeren Verfahren. Die Ableitung erfolgt
synchron; während eines einzelnen KDF-Aufrufs gibt es keinen neuen Abbruchpunkt.

Kompakte x64-Implementierung

Die Salsa-Zustände bleiben in XMM0 bis XMM3. XMM4 und XMM5 dienen als temporäre
Rotationsregister; XMM6 bis XMM9 halten die Werte für die Feed-forward-Addition.
Vier kompakte Doppelrunden ergeben Salsa20/8. SSE2 verarbeitet jeweils vier
32-Bit-Wörter parallel. Die nichtflüchtigen Register werden an der öffentlichen
ROMix-Schnittstelle gemäß Windows-x64-ABI gesichert und wiederhergestellt.

Die diagonale Wortanordnung orientiert sich an Colin Percivals SSE2-Referenz.
BlockMix schreibt gerade und ungerade Ergebnisse direkt in die jeweilige
Ausgabehälfte. ROMix verwendet für N = 2^18 eine Maske für den Matrixindex.
Eine vollständig ausgeschriebene Rundensequenz mit höherem Codebedarf wird
vermieden. Die gewählte Fassung priorisiert kompakte Schleifen; eine globale
Minimalgröße oder höchste Geschwindigkeit auf jedem Prozessor wird nicht behauptet.

Der gesamte native scrypt-Baustein einschließlich Wrapper und Speicherverwaltung
umfasst mit FASM 1.73.35 genau 1308 Byte Code. Die EXE wächst gegenüber dem mit
demselben Compiler gebauten Preview-2-Stand um 1536 Byte auf 232448 Byte. Die
Differenz enthält auch Dialogtexte, KDF-Verzweigungen und PE-Dateiausrichtung.
Der große Arbeitsspeicher wird zur Laufzeit angelegt und nicht in der EXE gespeichert.

Infodialog und Registry

Vier Radiobuttons stehen für neue Verschlüsselungen zur Verfügung:
  0: PBKDF2-HMAC-SHA-256, 600000 Iterationen
  1: Argon2id, 64 MiB, t=3, p=4 (Standard)
  2: Argon2id, 1024 MiB, t=3, p=4
  3: scrypt, 256 MiB, N=262144, r=8, p=1

Speichern schreibt den DWORD-Wert FileKdfMode unter
HKEY_CURRENT_USER\Software\Cryptext64. Abbrechen verwirft die neue Auswahl.
Ein ungültiger oder fehlender Wert verwendet weiterhin Argon2id mit 64 MiB.
Im Infodialog ist die KDF-Integration OpenAI Codex in Zusammenarbeit mit
NotCompatible zugeordnet. Bestehende Entwicklungsangaben bleiben erhalten.

Dateiformat und Kompatibilität

scrypt-Dateien verwenden CT64FILE-Version 2, KDF-ID 3 und Profil-ID 1.
Diese Kombination legt die oben genannten Parameter unveränderlich fest.
Unbekannte Profile werden vor einer Speicherallokation zurückgewiesen.
Die Entschlüsselung richtet sich nach dem Dateikopf, unabhängig von der aktuell
gespeicherten Auswahl. PBKDF2-Dateien und beide Argon2id-Profile bleiben lesbar.
Ältere Cryptext-Versionen ohne scrypt-Unterstützung können scrypt-Dateien nicht lesen.

AES-256-GCM, der 72-Byte-Dateikopf, die verschlüsselten Metadaten, 16-Byte-Tags,
Nonce-Bildung und AAD bleiben erhalten. Jeder Datensatz authentifiziert den
vollständigen Dateikopf einschließlich Verfahren und Profil. Das Header-Prüfen
vor der KDF ist zunächst strukturell; authentifiziert ist der Kopf erst nach
erfolgreicher GCM-Tag-Prüfung. Eine andere Implementierung benötigt daher neben
den KDF-Parametern auch das dokumentierte CT64FILE-Datensatzformat.

Betroffene Dateien

src/scrypt_native.asm: nativer scrypt-Kern und Windows-CNG-/Speicher-Wrapper.
src/fileformat.inc und fileformat_v1.asm: neue KDF-ID, Profil und Validierung.
src/crypto_cng.asm: Auswahl der Ableitung aus dem validierten Dateikopf.
src/kdf_settings.asm: Registry-Wertebereich 0 bis 3.
src/about.asm und sizeopt_module_data.asm: vierte Auswahl, deutsche/englische Texte.
src/Cryptext64.asm: Einbindung, Versionshinweis, Integrationsangabe, Stackreserve.
build.bat: FASM-Speicherlimit und aktualisierte Buildbeschreibung.

Prüfstand

Der vollständige Windows-PE64-Build wurde mit FASM 1.73.35 ausgeführt:
  bin/Cryptext64.exe: 232448 Byte
  bin/Cryptext64Shell.dll: 16384 Byte, optionale Explorer-Integration

40 automatisierte Tests sind bestanden. Dazu gehören der RFC-7914-Salsa20/8-
Vektor, skalare Salsa-/BlockMix-Vergleiche, scrypt-Ableitungen mit den vollständigen
256-MiB-Parametern gegen OpenSSL, Fehlerpfade und Löschung, vier Dialog-/Registry-
Auswahlen, PBKDF2-Kompatibilität, beide Argon2id-Profile einschließlich echter
1-GiB-Allokation sowie authentifizierte Dateivektoren.

Der scrypt-Maschinencode wird für die Tests unmittelbar mit FASM erzeugt und
unter Linux ausgeführt. Windows-API-Aufrufe werden dort durch Testimplementierungen
ersetzt. Die vorhandenen Format-/Dialogtests führen die Assembleranweisungen nach
gezielter Syntaxübersetzung für GNU as aus. Die vollständige Windows-GUI, echte
Windows-CNG-/Registry-Aufrufe und Dateioperationen wurden nicht unter Windows
getestet. Der erfolgreiche FASM-Build ist kein Ersatz für diesen Laufzeittest.

Die scrypt-Testdatei tests/Cryptext-v2-scrypt-test-vector.bin enthält öffentlich
bekannte Testdaten. Ihr Passwort lautet Test0815$#!. Die JSON-Begleitdatei nennt
Header, Schlüssel, Klartext und Prüfsumme. Zum Testen in Cryptext eine Kopie mit
der zusätzlichen Endung .$#! verwenden. Festes Salt und Nonce-Präfix dieser
Testdatei sind ausschließlich für reproduzierbare Tests bestimmt.

Referenzen und Lizenz

https://www.rfc-editor.org/rfc/rfc7914.html
scrypt-Referenzquellen und BSD-Lizenz: vendor/scrypt-reference/.
Argon2-Referenzquellen und Lizenz: vendor/argon2/.
Die Argon2-Einbindung bleibt als statisch eingebundener Referenz-Maschinencode
bestehen. Nur der neue scrypt-Baustein ist vollständig als FASM-Quelltext umgesetzt.
